fix(main-red): the LTX-2.5 VAE loader read the safetensors mmap through a uint16_t* it is not allowed to form (#674) - #688

…t16_t* it is not allowed to form (#674)

`main` has been RED on `sanitize-cpu (address,undefined)` since `cefacd2d0`
(#641, the LTX-2.5 landing). Baseline run 31724380111 reports one failing test
with one finding:

    30/423 Test  #30: test_ltx2_video ...***Failed
    src/vllm/model_executor/models/ltx2_loader.cpp:1288:91: runtime error:
    load of misaligned address 0x7f3c895be129 for type 'const uint16_t',
    which requires 2 byte alignment

REPRODUCED LOCALLY at `7965f12bf`, same site (`:1325` after the file shifted),
same class, full stack through `Ltx2LoadVaeWeights` <- `Ltx2VideoEngine::Load`:

    ltx2_loader.cpp:1325:91: runtime error: load of misaligned address
    0x7fffc81cc129 for type 'const uint16_t' ...
      #0 vllm::Ltx2LoadVaeWeights(...) ltx2_loader.cpp:1325
      #1 vllm::multimodal::Ltx2VideoEngine::Load(...) ltx2_video.cpp:777

THE DEFECT. `StTensor::data` points into the read-only safetensors mmap at
`8 + <JSON header length> + <sum of the preceding tensors' sizes>`. Not one of
those three terms is required to be even, so a BF16 tensor starting on an ODD
byte is an ordinary file and not a corrupt one. Forming a `const uint16_t*`
there and dereferencing it is UB on every target, and a real fault on the
strict-alignment ones this project builds and ships for: `build-test-cpu-arm64`,
Jetson/Orin (sm_110), Thor.

THE REPAIR is the seam, not a cast and not a suppression: `vt::LoadUnaligned`
(include/vt/unaligned.h), which is a `std::memcpy` with no alignment
precondition and compiles to the same single load where the address does happen
to be aligned. That seam exists BECAUSE of #301, the first time this class red
main. This is its third recurrence -- #301 (closed: cpu_ops.cpp, laguna.cpp),
#627 (open: qwen3_5_weights.cpp `TransposeBf16`), and now the VAE loader -- and
minimax_h3_vae_loader.cpp:87-101 already carried the repair AND its reason in
prose while the new loader reached main with the cast. Nothing gates the
pattern; that is recorded on #674 rather than fixed here.

THE COVERAGE THAT CAUGHT IT WAS ACCIDENTAL, which is the part worth fixing.
`ltx2_fixture`'s JSON header happens to land one VAE tensor on an odd byte
today; a rename or a reshape in that fixture retires the coverage silently and
leaves every assertion green. So this adds a case that FORCES the odd offset --
it writes the file itself and pads the counted JSON header by one space, keeping
whichever of the two parities is odd -- and then ASSERTS the parity it depends
on before loading:

    REQUIRE((reinterpret_cast<uintptr_t>(file.Get(name).data) % 2) == 1);

An edit that makes the address even now fails that REQUIRE instead of passing
while covering nothing. The values are chosen bf16-exact so the check is
equality rather than a band: a wrong-by-one-byte read is a hard failure.

RED, then GREEN, same binary, same command, `setarch -R` (this host SIGSEGVs
sanitizer builds on ASLR entropy otherwise, which reads exactly like a crash in
the code under test):

  RED   new case alone, unmodified src:
        ltx2_loader.cpp:1325:91: runtime error: load of misaligned address
        0x7ffff7fb005b ...  #1 DOCTEST_ANON_FUNC_153 test_ltx2_video.cpp:1189
  GREEN new case alone:  1 passed | 0 failed | assertions: 11 | 11 passed
  GREEN whole target:    1/1 Test #30: test_ltx2_video ... Passed 379.03 sec
  GREEN whole target, re-run on THIS head after rebase onto 43a6c55:
                         1/1 Test #30: test_ltx2_video ... Passed 157.35 sec

  cmake -S . -B build-sanitize -DVLLM_CPP_BUILD_TESTS=ON -DVLLM_CPP_CUDA=OFF \
        -DVLLM_CPP_SANITIZE='address,undefined'
  UBSAN_OPTIONS=print_stacktrace=1 \
  ASAN_OPTIONS=detect_leaks=1:strict_string_checks=1 VT_POOL_BYPASS=1 \
  setarch -R ctest --test-dir build-sanitize -R '^test_ltx2_video$'

NOT FIXED HERE, and reported rather than swept: 19 sibling sites form the same
pointer over `StTensor::data` in 11 other loaders, the widest being
`qwen3_dspark_weights.cpp:99`, which forms a `const int64_t*` and so needs
8-byte alignment. They are inventoried on #627, which owns the class and asks
for 27B/35B/Coder golden-md5 inertness evidence this repair has no GPU to
produce. Only the site that is red is touched.

The other half of the `cefacd2d0` main-red, the `device-leakage` DSR ratchet,
needs no change: `11cc1d589` already routed it through the platform seam.
Verified at `7965f12bf` by running both CI steps verbatim -- kcuda 0, DSR 32 ==
baseline 32, `test_device_leakage.py` 26/26 -- with
`scripts/device-leakage-baseline.json` untouched since `99b7443bd`, so it is a
repair and not a raised threshold. #553 is closed with that evidence.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: Claude:claude-opus-5 [Claude Code]

FOLLOWING_AGENTS_PROTOCOL

Mechanical rebase by the operator so a PASSED review can land. The row is one of
three reds blocking every open PR in the repository, and the only thing standing
between it and main was a conflict in two SHARED RECORD files -- the exact
"shared file = lock" pattern AGENTS.md names. No code conflict.

Both keyed records resolved BY KEY: main's version taken wholesale, this row's
scoped edits reapplied, unrelated keys verified byte-identical to main.

The defect this row fixes was introduced by the LTX-2.5 lane (cefacd2, #641),
which this operator coordinates; the fix and its review are another session's
work, and the review is a fresh one that verified the seam is a real
alignment-safe memcpy rather than a silenced diagnostic.

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5[1m] [claude-code]

# Conflicts:
#	.agents/roadmap_v1.md
#	docs/FEATURES.md